การจัดการแพ็คเกจ Frontend: การแก้ไข Dependency และความปลอดภัยในภูมิทัศน์การพัฒนาระดับโลก

ในโลกของการพัฒนาเว็บที่เชื่อมต่อถึงกันในปัจจุบัน โปรเจกต์ frontend แทบจะไม่ได้สร้างขึ้นจากศูนย์ แต่กลับต้องพึ่งพาระบบนิเวศขนาดใหญ่ของไลบรารีและเฟรมเวิร์กโอเพนซอร์ส ซึ่งจัดการผ่านเครื่องมือจัดการแพ็คเกจ (package managers) เครื่องมือเหล่านี้เปรียบเสมือนเส้นเลือดหลักของการพัฒนา frontend สมัยใหม่ ที่ช่วยให้สามารถทำงานซ้ำได้อย่างรวดเร็วและเข้าถึงฟังก์ชันการทำงานอันทรงพลังได้ อย่างไรก็ตาม การพึ่งพานี้ก็นำมาซึ่งความซับซ้อน โดยเฉพาะอย่างยิ่งในเรื่องของ การแก้ไข dependency (dependency resolution) และ ความปลอดภัย (security) สำหรับนักพัฒนาทั่วโลก การทำความเข้าใจในแง่มุมเหล่านี้จึงเป็นสิ่งสำคัญอย่างยิ่งในการสร้างแอปพลิเคชันที่แข็งแกร่ง น่าเชื่อถือ และปลอดภัย

พื้นฐาน: การจัดการแพ็คเกจ Frontend คืออะไร?

โดยแก่นแท้แล้ว การจัดการแพ็คเกจ frontend หมายถึงระบบและเครื่องมือที่ใช้ในการติดตั้ง อัปเดต กำหนดค่า และจัดการไลบรารีและโมดูลภายนอกที่โปรเจกต์ frontend ของคุณต้องพึ่งพา เครื่องมือจัดการแพ็คเกจที่แพร่หลายที่สุดในระบบนิเวศของ JavaScript ได้แก่:

• npm (Node Package Manager): เป็น package manager เริ่มต้นสำหรับ Node.js ซึ่งเป็นที่นิยมใช้กันอย่างแพร่หลายที่สุดและมีคลังแพ็คเกจ (repository) ที่ใหญ่ที่สุด
• Yarn: พัฒนาโดย Facebook โดย Yarn ถูกสร้างขึ้นเพื่อแก้ไขปัญหาด้านประสิทธิภาพและความปลอดภัยบางประการของ npm ในช่วงแรก มีฟีเจอร์ต่างๆ เช่น การติดตั้งที่แน่นอน (deterministic installs) และการแคชแบบออฟไลน์ (offline caching)
• pnpm (Performant npm): เป็นผู้เล่นหน้าใหม่ที่มุ่งเน้นประสิทธิภาพการใช้พื้นที่ดิสก์และเวลาในการติดตั้งที่รวดเร็วยิ่งขึ้น โดยใช้ content-addressable store และการทำ symlinking ให้กับ dependencies

เครื่องมือจัดการเหล่านี้ใช้ไฟล์กำหนดค่า ซึ่งที่พบบ่อยที่สุดคือ package.json เพื่อระบุรายการ dependency ของโปรเจกต์และเวอร์ชันที่ต้องการ ไฟล์นี้ทำหน้าที่เป็นพิมพ์เขียว แจ้งให้ package manager ทราบว่าต้องดึงและติดตั้งแพ็คเกจใดบ้าง

ความท้าทายของการแก้ไข Dependency

การแก้ไข dependency คือกระบวนการที่ package manager ใช้ในการกำหนดเวอร์ชันที่แน่นอนของแพ็คเกจทั้งหมดที่ต้องการ รวมถึง sub-dependencies ของแพ็คเกจเหล่านั้นด้วย ซึ่งกระบวนการนี้อาจซับซ้อนอย่างไม่น่าเชื่อเนื่องจากปัจจัยหลายประการ:

1. Semantic Versioning (SemVer) และช่วงเวอร์ชัน

แพ็คเกจ JavaScript ส่วนใหญ่ยึดตาม Semantic Versioning (SemVer) ซึ่งเป็นข้อกำหนดเกี่ยวกับวิธีการกำหนดและเพิ่มหมายเลขเวอร์ชัน หมายเลข SemVer โดยทั่วไปจะแสดงเป็น MAJOR.MINOR.PATCH (เช่น 1.2.3)

• MAJOR: การเปลี่ยนแปลง API ที่ไม่เข้ากัน (Incompatible API changes)
• MINOR: เพิ่มฟังก์ชันการทำงานใหม่ที่ยังคงเข้ากันได้กับเวอร์ชันเก่า (Backward-compatible)
• PATCH: การแก้ไขข้อบกพร่องที่ยังคงเข้ากันได้กับเวอร์ชันเก่า (Backward-compatible bug fixes)

ในไฟล์ package.json นักพัฒนามักจะระบุช่วงของเวอร์ชัน (version ranges) แทนที่จะเป็นเวอร์ชันที่แน่นอน เพื่อให้สามารถอัปเดตและแก้ไขข้อบกพร่องได้ ตัวระบุช่วงที่พบบ่อย ได้แก่:

• Caret (^): อนุญาตให้อัปเดตเป็นเวอร์ชัน minor หรือ patch ล่าสุดที่ไม่เปลี่ยนแปลงเวอร์ชัน major ที่ระบุ (เช่น ^1.2.3 อนุญาตเวอร์ชันตั้งแต่ 1.2.3 ไปจนถึงแต่ไม่รวม 2.0.0) ซึ่งเป็นค่าเริ่มต้นสำหรับ npm และ Yarn
• Tilde (~): อนุญาตการเปลี่ยนแปลงระดับ patch หากระบุเวอร์ชัน minor หรือการเปลี่ยนแปลงระดับ minor หากระบุเพียงเวอร์ชัน major (เช่น ~1.2.3 อนุญาตเวอร์ชันตั้งแต่ 1.2.3 ไปจนถึงแต่ไม่รวม 1.3.0)
• มากกว่าหรือเท่ากับ (>=) / น้อยกว่าหรือเท่ากับ (<=): กำหนดขอบเขตอย่างชัดเจน
• Wildcard (*): อนุญาตทุกเวอร์ชัน (ไม่ค่อยแนะนำให้ใช้)

ผลกระทบในระดับโลก: แม้ว่า SemVer จะเป็นมาตรฐาน แต่การตีความและการนำช่วงเวอร์ชันไปใช้อาจทำให้เกิดความแตกต่างเล็กน้อยระหว่าง package manager หรือแม้กระทั่งการติดตั้ง package manager ตัวเดียวกันในเวอร์ชันที่ต่างกันหากการกำหนดค่าไม่สอดคล้องกัน นักพัฒนาในภูมิภาคต่างๆ อาจมีความเร็วอินเทอร์เน็ตหรือการเข้าถึง package registry ที่แตกต่างกัน ซึ่งอาจส่งผลต่อผลลัพธ์ในทางปฏิบัติของการแก้ไข dependency ได้เช่นกัน

2. โครงสร้าง Dependency (Dependency Tree)

Dependency ของโปรเจกต์ของคุณจะสร้างโครงสร้างแบบต้นไม้ (tree structure) แพ็คเกจ A อาจต้องพึ่งพาแพ็คเกจ B ซึ่งในทางกลับกันก็ต้องพึ่งพาแพ็คเกจ C และแพ็คเกจ D ก็อาจต้องพึ่งพาแพ็คเกจ B ด้วยเช่นกัน package manager จะต้องสำรวจโครงสร้างต้นไม้นี้ทั้งหมดเพื่อให้แน่ใจว่าได้ติดตั้งเวอร์ชันของทุกแพ็คเกจที่เข้ากันได้

ปัญหาการชนกัน (Collisions): จะเกิดอะไรขึ้นถ้าแพ็คเกจ A ต้องการ LibraryX@^1.0.0 และแพ็คเกจ D ต้องการ LibraryX@^2.0.0? นี่คือปัญหา dependencyชนกันแบบคลาสสิก package manager จะต้องตัดสินใจว่าจะติดตั้ง LibraryX เวอร์ชันใด? บ่อยครั้งที่กลยุทธ์การแก้ไขจะให้ความสำคัญกับเวอร์ชันที่ต้องการโดยแพ็คเกจที่อยู่ใกล้กับราก (root) ของ dependency tree มากกว่า แต่ก็ไม่เป็นเช่นนั้นเสมอไปและอาจนำไปสู่พฤติกรรมที่ไม่คาดคิดได้หากเวอร์ชันที่เลือกไม่เข้ากันกับทุกตัวที่ต้องพึ่งพามัน

3. Lock Files: การรับประกันการติดตั้งที่แน่นอน

เพื่อต่อสู้กับความไม่แน่นอนของช่วงเวอร์ชันและเพื่อให้แน่ใจว่านักพัฒนาทุกคนในทีม รวมถึงทุกสภาพแวดล้อมการ deploy ใช้ชุด dependency ที่เหมือนกันทุกประการ package manager จึงใช้ lock files

• npm: ใช้ package-lock.json
• Yarn: ใช้ yarn.lock
• pnpm: ใช้ pnpm-lock.yaml

ไฟล์เหล่านี้จะบันทึกเวอร์ชันที่แน่นอนของทุกแพ็คเกจที่ติดตั้งในไดเรกทอรี node_modules รวมถึง transitive dependencies ทั้งหมดด้วย เมื่อมี lock file อยู่ package manager จะพยายามติดตั้ง dependencies ตามที่ระบุไว้ใน lock file อย่างแม่นยำ โดยข้ามตรรกะการแก้ไขช่วงเวอร์ชันสำหรับแพ็คเกจส่วนใหญ่ ซึ่งเป็นสิ่งสำคัญสำหรับ:

• ความสามารถในการทำซ้ำ (Reproducibility): รับประกันว่าการ build จะมีความสอดคล้องกันในเครื่องและเวลาที่แตกต่างกัน
• การทำงานร่วมกัน (Collaboration): ป้องกันปัญหา "บนเครื่องฉันทำงานได้นะ" โดยเฉพาะในทีมที่ทำงานกระจายอยู่ทั่วโลก
• ความปลอดภัย (Security): ช่วยให้สามารถตรวจสอบเวอร์ชันของแพ็คเกจที่ติดตั้งเทียบกับเวอร์ชันที่ปลอดภัยที่รู้จักได้ง่ายขึ้น

แนวปฏิบัติที่ดีที่สุดในระดับโลก: ควร commit ไฟล์ lock ของคุณไปยังระบบควบคุมเวอร์ชัน (version control system) (เช่น Git) เสมอ นี่อาจเป็นขั้นตอนที่สำคัญที่สุดเพียงขั้นตอนเดียวในการจัดการ dependencies อย่างน่าเชื่อถือในทีมระดับโลก

4. การอัปเดต Dependency ให้เป็นปัจจุบันอยู่เสมอ

กระบวนการแก้ไข dependency ไม่ได้สิ้นสุดแค่การติดตั้งครั้งแรก ไลบรารีมีการพัฒนา แก้ไขข้อบกพร่อง และแนะนำฟีเจอร์ใหม่ๆ อยู่เสมอ การอัปเดต dependency ของคุณอย่างสม่ำเสมอจึงเป็นสิ่งจำเป็นสำหรับประสิทธิภาพ ความปลอดภัย และการเข้าถึงความสามารถใหม่ๆ

• npm outdated / npm update
• Yarn outdated / Yarn upgrade
• pnpm outdated / pnpm up

อย่างไรก็ตาม การอัปเดต dependency โดยเฉพาะอย่างยิ่งกับช่วงเวอร์ชันแบบ caret อาจทำให้เกิดกระบวนการแก้ไข dependency รอบใหม่ และอาจนำไปสู่การเปลี่ยนแปลงที่เข้ากันไม่ได้ (breaking changes) หรือข้อขัดแย้งได้ นี่คือจุดที่การทดสอบอย่างรอบคอบและการอัปเดตทีละน้อยกลายเป็นสิ่งสำคัญ

ความจำเป็นเร่งด่วน: ความปลอดภัยในการจัดการแพ็คเกจ Frontend

ธรรมชาติของโอเพนซอร์สในการพัฒนา frontend เป็นจุดแข็ง แต่ในขณะเดียวกันก็นำเสนอความท้าทายด้านความปลอดภัยที่สำคัญ ผู้ไม่หวังดีอาจเข้าควบคุมแพ็คเกจยอดนิยม แทรกโค้ดที่เป็นอันตราย หรือใช้ประโยชน์จากช่องโหว่ที่รู้จัก

1. การทำความเข้าใจภาพรวมของภัยคุกคาม

ภัยคุกคามด้านความปลอดภัยหลักๆ ในการจัดการแพ็คเกจ frontend ได้แก่:

• แพ็คเกจที่เป็นอันตราย (Malicious Packages): แพ็คเกจที่ออกแบบมาโดยเจตนาเพื่อขโมยข้อมูล ขุด cryptocurrency หรือทำลายระบบ สิ่งเหล่านี้อาจถูกนำเข้ามาผ่านการ typosquatting (การลงทะเบียนแพ็คเกจที่มีชื่อคล้ายกับแพ็คเกจยอดนิยม) หรือโดยการเข้ายึดแพ็คเกจที่ถูกกฎหมาย
• Dependency ที่มีช่องโหว่ (Vulnerable Dependencies): แพ็คเกจที่ถูกกฎหมายอาจมีข้อบกพร่องด้านความปลอดภัย (CVEs) ที่ผู้โจมตีสามารถใช้ประโยชน์ได้ ช่องโหว่เหล่านี้อาจมีอยู่ในตัวแพ็คเกจเองหรือใน dependency ของมัน
• การโจมตีซัพพลายเชน (Supply Chain Attacks): เป็นการโจมตีในวงกว้างที่มุ่งเป้าไปที่วงจรการพัฒนาซอฟต์แวร์ การเข้าควบคุมแพ็คเกจยอดนิยมสามารถส่งผลกระทบต่อโปรเจกต์ปลายนับพันหรือนับล้าน
• Dependency Confusion: ผู้โจมตีอาจเผยแพร่แพ็คเกจที่เป็นอันตรายที่มีชื่อเดียวกับแพ็คเกจภายในไปยัง public registry หากระบบ build หรือ package manager กำหนดค่าไม่ถูกต้อง ก็อาจดาวน์โหลดเวอร์ชันสาธารณะที่เป็นอันตรายแทนเวอร์ชันส่วนตัวที่ตั้งใจไว้

การเข้าถึงของภัยคุกคามในระดับโลก: ช่องโหว่ที่ค้นพบในแพ็คเกจที่ใช้กันอย่างแพร่หลายสามารถส่งผลกระทบทั่วโลกได้ในทันที ซึ่งส่งผลต่อแอปพลิเคชันที่ใช้โดยธุรกิจและบุคคลทั่วไปในทวีปต่างๆ ตัวอย่างเช่น การโจมตี SolarWinds แม้จะไม่ใช่แพ็คเกจ frontend โดยตรง แต่ก็ได้แสดงให้เห็นถึงผลกระทบอย่างใหญ่หลวงของการเข้าควบคุมส่วนประกอบซอฟต์แวร์ที่เชื่อถือได้ในซัพพลายเชน

2. เครื่องมือและกลยุทธ์เพื่อความปลอดภัย

โชคดีที่มีเครื่องมือและกลยุทธ์ที่แข็งแกร่งเพื่อลดความเสี่ยงเหล่านี้:

ก) การสแกนช่องโหว่

package manager ส่วนใหญ่มีเครื่องมือในตัวเพื่อสแกนหาช่องโหว่ที่รู้จักใน dependency ของโปรเจกต์ของคุณ:

• npm audit: ทำการตรวจสอบช่องโหว่ของ dependency ที่ติดตั้งไว้ นอกจากนี้ยังสามารถพยายามแก้ไขช่องโหว่ที่มีความรุนแรงต่ำได้โดยอัตโนมัติ
• Yarn audit: คล้ายกับ npm audit โดยให้รายงานช่องโหว่
• npm-check-updates (ncu) / yarn-upgrade-interactive: แม้ว่าจะเป็นเครื่องมือสำหรับการอัปเดตเป็นหลัก แต่ก็สามารถช่วยชี้ให้เห็นแพ็คเกจที่ล้าสมัย ซึ่งมักเป็นเป้าหมายของการวิเคราะห์ความปลอดภัย

ข้อมูลเชิงลึกที่นำไปปฏิบัติได้: รันคำสั่ง npm audit (หรือคำสั่งที่เทียบเท่าสำหรับ manager อื่นๆ) ใน CI/CD pipeline ของคุณอย่างสม่ำเสมอ และถือว่าช่องโหว่ที่มีความรุนแรงระดับวิกฤตและสูงเป็นตัวบล็อกการ deploy

ข) การกำหนดค่าและนโยบายที่ปลอดภัย

• ไฟล์ .npmrc ของ npm / .yarnrc.yml ของ Yarn: ไฟล์กำหนดค่าเหล่านี้ช่วยให้คุณสามารถตั้งค่านโยบายต่างๆ เช่น การบังคับใช้ SSL ที่เข้มงวด หรือการระบุ registry ที่เชื่อถือได้
• Private Registries: สำหรับความปลอดภัยระดับองค์กร ควรพิจารณาใช้ private package registry (เช่น npm Enterprise, Artifactory, GitHub Packages) เพื่อโฮสต์แพ็คเกจภายในและทำมิเรอร์แพ็คเกจสาธารณะที่เชื่อถือได้ ซึ่งจะช่วยเพิ่มชั้นของการควบคุมและการแยกส่วน
• ปิดการใช้งานการอัปเดต package-lock.json หรือ yarn.lock อัตโนมัติ: กำหนดค่า package manager ของคุณให้ล้มเหลวหากไม่มีการปฏิบัติตาม lock file ระหว่างการติดตั้ง เพื่อป้องกันการเปลี่ยนแปลงเวอร์ชันที่ไม่คาดคิด

ค) แนวปฏิบัติที่ดีที่สุดสำหรับนักพัฒนา

• ใส่ใจกับที่มาของแพ็คเกจ: เลือกใช้แพ็คเกจจากแหล่งที่เชื่อถือได้ มีการสนับสนุนจากชุมชนที่ดี และมีประวัติการตระหนักถึงความปลอดภัย
• ลดจำนวน Dependencies: ยิ่งโปรเจกต์ของคุณมี dependency น้อยเท่าไหร่ พื้นที่ในการโจมตี (attack surface) ก็จะยิ่งเล็กลงเท่านั้น ควรตรวจสอบและลบแพ็คเกจที่ไม่ได้ใช้ออกอย่างสม่ำเสมอ
• ปักหมุด Dependencies (อย่างระมัดระวัง): แม้ว่า lock files จะเป็นสิ่งจำเป็น แต่บางครั้งการปักหมุดเวอร์ชันที่เฉพาะเจาะจงและผ่านการตรวจสอบอย่างดีของ dependency ที่สำคัญก็สามารถให้ความมั่นใจเพิ่มขึ้นอีกชั้นหนึ่ง โดยเฉพาะอย่างยิ่งหากช่วงเวอร์ชันกำลังก่อให้เกิดความไม่เสถียรหรือการอัปเดตที่ไม่คาดคิด
• ทำความเข้าใจสายของ Dependency (Dependency Chains): ใช้เครื่องมือที่ช่วยให้เห็นภาพ dependency tree ของคุณ (เช่น npm ls, yarn list) เพื่อทำความเข้าใจว่าคุณกำลังติดตั้งอะไรอยู่จริงๆ
• อัปเดต Dependencies อย่างสม่ำเสมอ: ดังที่ได้กล่าวไปแล้ว การอัปเดต patch และ minor release ให้เป็นปัจจุบันอยู่เสมอเป็นสิ่งสำคัญในการแก้ไขช่องโหว่ที่รู้จัก ควรทำกระบวนการนี้ให้เป็นอัตโนมัติเท่าที่ทำได้ แต่ต้องมีการทดสอบที่แข็งแกร่งเสมอ
• ใช้ npm ci หรือ yarn install --frozen-lockfile ใน CI/CD: คำสั่งเหล่านี้ช่วยให้มั่นใจได้ว่าการติดตั้งจะยึดตาม lock file อย่างเคร่งครัด ป้องกันปัญหาที่อาจเกิดขึ้นหากมีใครบางคนในเครื่องมีเวอร์ชันที่แตกต่างกันเล็กน้อยติดตั้งอยู่

3. ข้อควรพิจารณาด้านความปลอดภัยขั้นสูง

สำหรับองค์กรที่มีข้อกำหนดด้านความปลอดภัยที่เข้มงวดหรือองค์กรที่ดำเนินงานในอุตสาหกรรมที่มีการกำกับดูแลสูง ควรพิจารณา:

• Software Bill of Materials (SBOM): เครื่องมือสามารถสร้าง SBOM สำหรับโปรเจกต์ของคุณ โดยระบุส่วนประกอบทั้งหมดและเวอร์ชันของมัน ซึ่งกำลังกลายเป็นข้อกำหนดทางกฎหมายในหลายภาคส่วน
• Static Analysis Security Testing (SAST) และ Dynamic Analysis Security Testing (DAST): ผสานรวมเครื่องมือเหล่านี้เข้ากับเวิร์กโฟลว์การพัฒนาของคุณเพื่อระบุช่องโหว่ในโค้ดของคุณเองและโค้ดของ dependencies
• Dependency Firewall: ใช้นโยบายที่บล็อกการติดตั้งแพ็คเกจที่ทราบว่ามีช่องโหว่ร้ายแรงหรือที่ไม่เป็นไปตามมาตรฐานความปลอดภัยขององค์กรของคุณโดยอัตโนมัติ

เวิร์กโฟลว์การพัฒนาระดับโลก: ความสอดคล้องกันข้ามพรมแดน

สำหรับทีมที่ทำงานแยกย้ายกันข้ามทวีป การรักษาความสอดคล้องในการจัดการแพ็คเกจเป็นสิ่งสำคัญ:

• การกำหนดค่าแบบรวมศูนย์: ตรวจสอบให้แน่ใจว่าสมาชิกในทีมทุกคนใช้เวอร์ชันของ package manager และการตั้งค่าการกำหนดค่าเดียวกัน และจัดทำเอกสารไว้อย่างชัดเจน
• สภาพแวดล้อมการ Build ที่เป็นมาตรฐาน: ใช้เทคโนโลยีคอนเทนเนอร์ (เช่น Docker) เพื่อสร้างสภาพแวดล้อมการ build ที่สอดคล้องกัน ซึ่งรวบรวม dependencies และเครื่องมือทั้งหมดไว้ ไม่ว่าจะเป็นเครื่องคอมพิวเตอร์หรือระบบปฏิบัติการของนักพัฒนาคนใดก็ตาม
• การตรวจสอบ Dependency อัตโนมัติ: ผสานรวม npm audit หรือเทียบเท่าเข้ากับ CI/CD pipeline ของคุณเพื่อตรวจจับช่องโหว่ก่อนที่จะไปถึง production
• ช่องทางการสื่อสารที่ชัดเจน: สร้างระเบียบการสื่อสารที่ชัดเจนสำหรับการหารือเกี่ยวกับการอัปเดต dependency ข้อขัดแย้งที่อาจเกิดขึ้น และคำแนะนำด้านความปลอดภัย

บทสรุป

การจัดการแพ็คเกจ frontend เป็นส่วนที่ซับซ้อนแต่ขาดไม่ได้ในการพัฒนาเว็บสมัยใหม่ การเรียนรู้การแก้ไข dependency ผ่านเครื่องมืออย่าง lock files เป็นสิ่งสำคัญอย่างยิ่งในการสร้างแอปพลิเคชันที่เสถียรและสามารถทำซ้ำได้ ในขณะเดียวกัน แนวทางเชิงรุกด้านความปลอดภัย การใช้ประโยชน์จากการสแกนช่องโหว่ การกำหนดค่าที่ปลอดภัย และแนวปฏิบัติที่ดีที่สุดของนักพัฒนา ก็เป็นสิ่งที่ต่อรองไม่ได้ในการปกป้องโปรเจกต์และผู้ใช้ของคุณจากภัยคุกคามที่เปลี่ยนแปลงอยู่ตลอดเวลา

ด้วยการทำความเข้าใจความซับซ้อนของการกำหนดเวอร์ชัน ความสำคัญของ lock files และความเสี่ยงด้านความปลอดภัยที่มีอยู่เสมอ นักพัฒนาทั่วโลกสามารถสร้างแอปพลิเคชัน frontend ที่ยืดหยุ่น ปลอดภัย และมีประสิทธิภาพมากขึ้น การยึดมั่นในหลักการเหล่านี้ช่วยให้ทีมระดับโลกสามารถทำงานร่วมกันได้อย่างมีประสิทธิภาพและส่งมอบซอฟต์แวร์คุณภาพสูงในภูมิทัศน์ดิจิทัลที่เชื่อมต่อถึงกันมากขึ้น